home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000063_owner-urn-ietf _Mon Oct 21 15:53:22 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  5KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA28848 for urn-ietf-out; Mon, 21 Oct 1996 15:53:22 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA28843 for <urn-ietf@services.bunyip.com>; Mon, 21 Oct 1996 15:53:16 -0400
  3. Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA23123  (mail destined for urn-ietf@services.bunyip.com); Mon, 21 Oct 96 15:53:08 -0400
  5. Message-Id: <9610211953.AA23123@mocha.bunyip.com>
  6. Received: by privateer.windrose.omaha.ne.us; Mon Oct 21 14:54 CDT 1996
  7. From: "Ryan Moats" <jayhawk@ds.internic.net>
  8. To: "Martin J Duerst" <mduerst@ifi.unizh.ch>
  9. Cc: "urn-ietf@bunyip.com" <urn-ietf@bunyip.com>
  10. Date: Mon, 21 Oct 96 14:57:48 
  11. Priority: Normal
  12. X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE
  13. Mime-Version: 1.0
  14. Content-Type: text/plain; charset="us-ascii"
  15. Content-Transfer-Encoding: 7bit
  16. Subject: Re: [URN] Pre release of URN Syntax document....
  17. Sender: owner-urn-ietf@services.bunyip.com
  18. Precedence: bulk
  19. Reply-To: "Ryan Moats" <jayhawk@ds.internic.net>
  20. Errors-To: owner-urn-ietf@bunyip.com
  21.  
  22. Since I've seen Patrik's comments, I'll only comment on things that
  23. he didn't and then add mine in a reply to his comments in a minute...
  24.  
  25. On Mon, 21 Oct 1996 19:38:53 +0100 (MET), Martin J Duerst wrote:
  26.  
  27. >Ryan Moats wrote:
  28. >
  29. >Well, first a great scream of joy and congratulations that you have
  30. >made it with iso10646/UTF-8. More comments on that below.
  31.  
  32. I'll admit that it was a last minute addition, and did hold things up a
  33. bit while some issues were sorted out.  However, might as well get things
  34. going now...
  35.  
  36. >>1.1 Namespace Identifier Syntax
  37. >>
  38. >>   The following is the syntax for the Namespace Identifier. To (a) be
  39. >>   consistent with all potential resolution schemes and (b) not put any
  40. >>   undue constraints on any potential resolution scheme, the syntax for
  41. >>   the Namespace Identifier is:
  42. >>
  43. >>   <NID>         ::= <letter> [ <let-hyp> ]
  44. >>
  45. >>   <let-hyp>     ::= <letter> | "-"
  46. >>
  47. >>   <letter>      ::= any one of the 52 alphabetic characters A through Z
  48. >>                     in upper case and a through z in lower case
  49. >>
  50. >>   This is slightly more restrictive that what is stated in RFC 1738 [4]
  51. >>   (which allows the period "."). Further, the Namespace Identifier is
  52. >>   case insensitive, so that "ISBN" and "isbn" refer to the same
  53. >>   namespace.
  54. >
  55. >Kind of disappointed that i18n didn't make it for NIS. But it's probably
  56. >not necessary. And if it becomes necessary, we could just create a new
  57. >NIS, "i" for short, and could prefix it. Or am I stretching my understanding
  58. >of URN syntax too much?
  59.  
  60. I don't like this,  because it precludes freedom in the resolving scheme.
  61.  
  62. >One main problem is that while the URL/URI didn't specify any
  63. >character semantics, this proposal defines everything in terms
  64. >of characters.
  65. >For URL/URIs, it was not defined what character, or part of a
  66. >character, bytes above 0x7F were denoting, nor was one even sure,
  67. >after reading the specs, that an "A" in an URL was supposed to be
  68. >the character "A". One only got a certain confidence in such
  69. >coincidences after having a look at some actual examples.
  70. >This had some advantages, as it left open any decisions for
  71. >the individual protocols, and it also considered cases where
  72. >the information in the URL did not have anything to do with
  73. >characters (e.g. something like the data URL).
  74. >So I think the spec should go more in the direction of:
  75. >
  76. >- If an NSS contains characters, these should be encoded using UTF-8.
  77. >- If an NSS contains something else (e.g. pure data), this can be
  78. >    encoded directly using %HH.
  79. >- If an NSS, for some reasons, decides to use a different encoding
  80. >    for characters, this is not prohibited (but not suggested).
  81. >
  82. >When the second point is introduced, the third cannot be avoided
  83. >anyway, because a NSS scheme may just define that it does %HH encoding
  84. >on its own, using a different character syntax, and the NSS encoding
  85. >of the characters in that scheme would only trivially encode
  86. >ASCII characters (with lots of "%" in it).
  87. >
  88. >This will also mean that NSS are not limited to be correct UTF-8
  89. >sequences.
  90.  
  91. I'll have to think about all of this, but my first reaction is that I don't like
  92. it.
  93.  
  94. The rest will come in the next mail message...
  95.  
  96. >>2. Grand-fathering
  97. >>
  98. >>   To allow for grand-fathering of existing naming systems (as required
  99. >>   by [2]), the Namespace Specific String shall be considered an "opaque
  100. >>   string" in the sense of structure except as mentioned in Section 1.
  101. >
  102. >Just the fact that it is considered a string of characters in all cases
  103. >is somewhat restricting.
  104.  
  105. Oh, I see.  I wasn't thinking in terms of strings of characters, I was thinking in
  106. terms of string of octets. Guess I should change this, then.
  107.  
  108. Lexica Equivalence will come in the next message.
  109.  
  110. Ryan
  111.